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Work Flow 
Chaining 
Services 
(WfCS) 


Abstract data from process of obtaining data via services above 
Access sensors and data via Internet and use services similarly 
to how “Google Earth” is used 

User chains multiple services from various sensors and data 

sen/ice providers together as needed 

Built on top of GMSEC and cFE 2 
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“I want a package delivered” 


Front end of service 
“Generic request” 

Service Aggregator 


Back end “plug-ins^ 
to fulfill service 



Deliver 

Package 

(DP) 


UPS 


FedEx 



• User discovers service on Internet with search tools 

• User picks desired service, pays and doesn’t get involved in 
details of how service is provided 

• New services can be easily plugged in and removed thus 
circumventing risk of obsolescence 

• Fault tolerant because user can locate and connect to alternative service 
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Example: Discovering and Tasking 
-1 Sensors (OGC OWS-4 Demo) “ A “ 


Front end of service 
“Generic request” 



Service Aggregator 


Back end “plug-in” 
to fulfill service 


EO-1 Tasking Map 


Sensor 

Planning 

Service 

(SPS) 




•Wrap EO-1 satellite in 
SensorML and publish 
its capabilities 

• Enable generic command 
/tasking request via SPS 

• Enable generic alert 
services via SAS 


Database 

• Store capabilities 

• Process user query and 

• return the result 


EO-1 Tasking Webserver 

ASPEN (Ground Planner) 

• Accept user goal requests 

• Automatically sort by priority 

• Perform auto-sync with onboard 
planner- CASPER 
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SPS Example Using ST5 Built 
onTopofGMSEC 


Front end of service 
“Generic request” 


Back end “plug-irr 
Service Aggregator *° service 


Sensor Types 
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Future Expansion 




• Validated new “back-end” predictive models which predicted problems for 
selected subsystems (SSR, RF Link, Power) and then autonomously initiated 
corrective actions through planning system before problem occurred 

- Unique innovation-Models self-update overtime using real-time 
telemetry (e.g. as solar array degrades, charge current for battery changes over 
time, therefore model of state of battery has to change) 

Used GSFC Mission Services Evolution Center (GMSEC) message bus to 
enable communications between 
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xample of Service Chain to Fulfill 
fcience Data Processing Needs . 




Sensor 

Planning 

Services 

(SPS) 



Sensor Alert 

Services 

(SAS) 




Work Flow Chaining Services 
(WfCS)— e.g BPEL 


Sensor 
Observation 
Services 
(SOS) 

Subset raw data by band or time 
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Services 
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Put on Map background 


Filter by featun 
area, time 
(Discovery by 
\feature) 


Find (Discover) sensors that cal 
image wildfire 




Web 

Coverage 
Service (WCS) 

ubset by geographic 
area or time of acquisition / 


rocess/data and georectify- 
e.g.levqllg, also Classify-Largel! 



vantages of SOA for Space Sensors 


■ Networked standardized interface connections, loosely coupled 

• Components connected at run-time 

■ Enables discovery of services 

■ Hides details of how service performed (encapsulated 
implementation) 

■ Fault tolerant 

• Since connection occurs at run-time, if service not available, a 
component can find or “discover” an alternative service and if 
unavailable, can connect to another instance of the service if available 

• Troubleshooting is easier because information is provided at component 
and services level 

■ Highly reusable 

• Standardized, networked “plug and play” interfaces 

■ Scalable 

• Interactions between services and clients independent of location and 
numbers 

■ Sustaining engineering for constellation simplified 

• Can initiate new instance of service or alternative service and then 

disconnect old services 

Taken from: Hartman, Hoebel; “Lightweight Service Architectures for Space Missions", SMC-IT 2006, 

Pasadena, Ca 












On-board science processing, 
classification and autonomous 
decision making 


Key Capabilities Implemented to Enable EO-1 
Sensor Webs & Support “Backend” of SPS 


Science data productB generate 
on-board and evaluated by 
autonomous science algorithms 


Triggered observations 
and new targets from 
tho ground sorted and 
integrated Into schedule 



Clouds - Roods 

Thermal - Ice breakup 

Snow/Water/ice - Etc. . . 



Tape transfer of data 


converted to high 
speed electronic 
transfer and automated 
product generation 


Raw 
Data 
f Dump 


• Automated load generation 

• Automated real-time uplink 


» Automated maneuver and Image 
generation for Individual targets 
• Broadcast algorithm results 


• Automated meta data 

• Science data generation 

• Acquisition tracking reporting 



Multiple Users: 

- CSFC 

- JPL 



- Monitors ground sensors 

- Monitors MODIS direct broadcasts 

- Screens GOES / DMSP data for 
least cloudy alternate targets 
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Data Distribution 

| I and Archive 

System Management 
Spacecraft Health and Safety 


User Interface auto -sorts and prioritizes tasking 
requests and builds goal file for upload 
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SE flight Software Architecture 


Band Extraction 


Image 


Overflight 

Times 


CASPER Planner 
- response in 10s of minutes 


Observation 
Goals 


Onboard Science 
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/ High level \ Plans of Activities 


L2 - Model-based 

/ S/C State \ (high level) 

Information \ 

Mode Identification & 
Reconfiguration 

SCL - response in seconds with rules, scripts 
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S/C State / 


Commands 
(low level) 


Autonomous 

Sciencecraft 


EO 1 Conventional Flight Software 
reflexive response 


Conventional 

Systems 


Sensor Telemetry / 


\ Control Signals 
\ (very low level) 



Spacecraft Hardware 
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iriginil Operations Flow to Task 
ensors & Access Science Data 
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science 

data 


targets | J targets, engineering requests 
contacts 


White Sands 


station j 
in-views 


Engineer 


I weekly schedule 


Mission 

Planner 


overflights J, selected weekly schedule 


tracking 

data 


MOPSS 


1 daily activities 
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viseji Operations Flow To Task 
ensors and Access Science Data.Using n A 5A 
nboard Autonom 


processed 

science 

data 


targets, 
engineering 
requests SOA Users 

,/targets 


USGS 


GSFC 


targets 


Science 

Processing 


WWW 


I weekly goa 


raw 


White Sands 


science 


SPS 


ASPEN 


[ daily goals Note that engineer and 

mission planner removed 
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tracking 

data 
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commands 
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Scenes and ground contacts are selected automatically based on scene* 
priorities 

World Wide Web interface for requesting and acquiring observations 
High-level scene and contact “goals” are uploaded to the spacecraft 
instead of detailed command sequences 
Execution sequence can be automatically changed on-board 
Priority observations can be requested and acquired within hours 
Science data is immediately available for analysis on-board compared to 
days or weeks 
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arious EO-1 Sensor Web Experiments 
Conducted 


Volcano Tilt meters, 
Kilau&a, Mauna Loa 
U96S Hawaii 


EO-1 responds 


to triggers ard 
has onboard trimers 
for s new, water, io5\ 
land, thermal and cbuda 


MOOiS (Terra and Aqua) 

U9«d to detect hot spots 
for firee, volcanoes. 

Also, used for flood detection 
MDDNOC flJrlv. of Hawaii) 
RapicFiregJniv. of Md.) 
Dartmouth Flood Observatory 


JBc QOES/O 
aT “ acreenli 


GOES/0MSP used for doud 
screening near real-time 


MOPSS: Mission iterations Planning 
and SchsdiJing Syet#m<GSFC) 

SGM: Science Goel monitor («3SFC) 

ASPEN: Planning fi scheduling (JFL) 
EPOS: Earth Phenomena Obeervng 
System - Cloud acreenhg (Draper) 

On-booid: 

ASE: Autonomous Sdenoecrafl 
Experiment (JPl) 

Livingstons (Ames) 

— Onboard diagnostic tool 

Comminication infrastructures 

Cellular based architecture for spacecraft 
using phased array antennas 03SFC.6RC, 
Ga Tech, Uni v. of Colorado) 


Triggers 


Onboard & Ground Tools 


Uses 




grounu ot un~uroii piannii 
scheduling systems and 


Correlate latest fire 
location information 
with MODIS imagery 


UMD Natural 
Hazards 




Active Fires 
Detectio n Ma p 


Aqua or Terra 
MODIS data 
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otyp$ Workflow Chain Service (WfCS) to 
ble EO-1 Sensor Web to Targets National"*™ 
rioritv Wildfires 


Identify NIFC-tracked| 
Wildfire Incidents! 

Large Incidents - August 21 , 2003 j 
Roberts Fire 


Fire location confirmed 
— d se lected for imaaina r-^—- 



MODIS Rapid Response 
Active Fire Detections 


1 Goddard 
Space 
. : llght 
i Center 




ple>of Rapid Delivery of Information for 
cisions for EO-1 Sensor Web with WfCS 


In this image, 
burned areas 
appear red 
while the 
unbumed areas 
appear green. 
The blue bum 
perimeter vector 
is based on 
ground data. 


On 11-2-03, the NASA 
Wildfire SensorWeb was 
employed to collect data on 
the burn scars resulting 
from the Simi Valley, Val 
Verde and Pirn fires in 
Southern California. 

MODIS active fire 
detections for the duration 
of the event were used to 
target an acquisition by the 
ALI and Hyperion 
instruments onboard 
EO-1. Such data are 
employed by the USDA 
Forest Sen/ice for Burned 
Area Emergency 
Rehabilitation mapping. 
BAER maps are used to 
target high risk areas for 
erosion control treatments. 
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tegratfed Flow forSensor Planning Service 
for EO-1 : First Step . 


Pk 

NASA 



Science 

Alerts 


Scientists 


Science 

Campaigns 


Observation 

Requests 


Science Event Manager 
Processes alerts and 
Prioritizes response observations 


EO-1 Flight Dynamics 

Tracks, orbit, overflights, 
momentum management 


ASPEN 

Schedules observations on EO-1 


Updates to 
onboard plan 





GSFC Mission Systems Evolution Center (GMSEC) 
Core Flight Executive (cFE) 

Core Flight System (CFS) 

SensorML 

OGC S ensor Web Enablement (SWE) standar ds 



Services'* ) Creata ) )' nt " rate )) Depl °^ ) Manag ^ 


Application Services 
SensorML Archives Event Processing Others TBC 


Interoperability and Meta-Language Services 
SensorML IRC Others TBD 


hi 


GMSEC 
• Grou 


Distributed Multi-Protocol Message Bus 


cFE 

For Space 
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Goddard 


Center 


Ground System Testbed 


Core Flight Executive (cFE) on CHT 


ASIST 

Primary 


GMSEC Extended to S/C Bus-Onboard lntegrate$ ASA 
"lessage Bus Demonstration (December 2005) 


GMSEC Bus 

r 


Command H Telemetry 


Ingest 


Output 


cFF 


Bus 


Livingstone 

Adaptor 


* 

ASIST 

Secondary § 

\ 


DC - Data Center 

ASIST - Advanced Spacecraft Integration and System Test 
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Goddard 


Flight 

Center 


Command 


Telemetry 

Output 


Power Model 


via Berkeley & Wallops 
Ground Stations (UDP) 


Fairmont, WV 


GMSEC Bus 


via TCP/IP 


Goddard Space Flight Center 


ST-5 Constellation 


CHIPS - Cosmic Hot Interstellar Plasma Spectrometer 
ST-5 - Space Technology 5 


DC - Data Center 
ASIST - Advanced Spacecraft Integration and System Test 


Ingest 


Mobile agent -autonomous software module that 
can easily be moved around a network 

Models transformed into mobile agents 
• Worked with Solid State Recorder agent (model) first 


Adapter built to make compatible with both 
GMSEC and Core Flight Executive (cFE) 


cFE Bus 


Demonstrated capability to move software 
running on GMSEC onboard to run under 


Demonstrates beginning step to transform 
missions from central control to distributed control 


Adapter 


SSR Model 
Agent 


Power Model 
Agent 


via self-managing software 


Adapter 


SSR Model 
Agent 


10 








■ GMSEC providing framework for C3I work in the Constellation Program 

• Will be used for ground and constellation of laboratories 

■ Two recent follow-on 3 year awards from AIST ESTO call for proposal to 
extend ST5 efforts 

• An Inter-operable Sensor Architecture to Facilitate Sensor Webs 
in Pursuit of GEOSS 

• Key topic - Interoperability and demonstration of service 
oriented architecture for space missions and sensor webs 

• PI: Dan Mandl - 3 year effort 

• Using Intelligent Agents to Form a Sensor Web for Autonomous 
Mission Operations 

• Key topic distributed mission control 

• Extend effort depicted on slide 16 in which ST-5 components 
turned into mobile agents for use onboard spacecrafts with 
GMSEC/CFS 

• PI: Ken Witt/ISR Co-1 Dan Mandl/GSFC - 3 year effort 


Scientific Research (ISR) 

• Building GMSEC compliance tester for new components 

• Help to synergize other ESTO awards with above mentioned awards 

• Integrate ROME in collaboration with Capitol College into TRMM, GLAST 
and MMS 

■ West Virginia Challenge Grant (set-aside) to be applied to develop Sensor 
Modeling Language (SensorML) schemas for follow-on SOA efforts 

• SensorML schemas will describe sensor capabilities and once put in 
online registries, will enable discovering of those capabilities on the 
Internet 

■ Open Geospatial Consortium (OGC) ongoing testbed effort OGC Web 
Services 4 (OWS-4) June 2006- December 2006 

• 200 member organization of OGC 

• 40 organization participating in OWS-4 

• Sensor Planning Service (SPS) one of key services being demonstrated 
with EO-1 
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Additional info at: 
and 

Other Team Members: 


eo1.gsfc.nasa.gov 

ase.jpl.nasa.gov 


Jeff D’Agostino (Hammers), Seth Shulman (Operations'Lead, 
HoneywellT Lawrence Ong (SSAI), Stephen Ungar (EO-1 




GSFC: Jerry Hengemihle, Scott Walling & Bruce Trout (Microtel), 

_ (Ha " ‘ ‘ 

jywell), I 

Scientist), Thomas Brakke 

JPL: Steve Chien (ASE Principal Investigator), Rob Sherwood 
ASE Experiment Mgr), Daniel Tran (Software Lead), Rebecca 
“astano (Onboard Science Lead), Ashley Davies (Science Lead), 
Gregg Rabideau, Ben Cichy, Nghia Tang 

Interface & Control Systems (ICS): Darrell Boyer, Jim Van 
Gaasbeck 

Univ. of Maryland: Rob Sohlberg (Wildfire Sensor Web) 

Univ. of AZ: Victor Baker, Felipe Ip, James Dohm 

ASU: Ronald Greeley, Thomas Doggett 

MIT LL: Michael Griffin, Hsiao-hua Burke, Carolyn Upham 
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ASE - Autonomous Sciencecraft Experiment 
ASIST - Advanced Spacecraft Integration and System Testing 
ASPEN - Automated Scheduling Planning Environment 
CASPER - Continuous Activity Scheduling Planning Execution 
and Replanning 

CMS - Command Management Systems 

MOPSS - Mission Operations Planning and Scheduling Systems 

SCL - Spacecraft Command Language 
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derlying “Plug and Play” Message Bus Architecture-^^ 
ddard Mission Services Evolution Center. (GMSEC) 


GMSEC architecture provides a 
scalable and extensible ground 
and flight system approach 

• Standardized messages 
formats 

• Plug-and-play components 

• Publish/Subscribe protocol 

• Platform transparency 

• ST5 first mission to be 
totally GMSEC compliant 

More info at: http://amsec.qsfc.nasa.gov 
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bre Flight Executive (cFE), an 
xtension for GMSEC for. Flight SW 


cFE provides a framework that 
simplifies the development and 
integration of applications 

■ Layered Architecture - software of a layer 
can be changed without affecting the 
software of other layers 

■ Components communicate over a standard 
message-oriented software bus, therefore, 
eliminating the need to know the details of 
the lower layers of inter-networking. 

■ Software components can be developed and 
reused from mission to mission. 

■ Developed by Flight SW Branch at GSFC 

■ To be used on LRO 

■ More info at: http://qmsec.qsfc.nasa.gov 



Executive Service! 


Device Abstraction 


OS Abstraction 


OSl ••• OS n Operating Systems 


Device Drivers 



HW 



Components 
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xampfe of Rapid Mission Configuration Using 
iMSEC Interoperable Catalog Components 


► Front End Processors 
+ Simulators 


( SIMSS 


► Scripting 
Control 


Pad 

Python 

SCL 


► Telemetry ♦ ► GMSEC APIs/Ops Systems 

Command Systems 



c,c. 

Linux ' 

Astsr 

Delphi 

Windows 

(^Eciipr^) 

avaT^) 

Solaris 

InControING 

( Peri 


nos 

PyUton 




COTS Middleware: SCL, Tibco Rendezvous, Tibco SmartSockets, Eivin 


MTASS 


RPTS 

(a U (or os) 

AMPS 

System Monitoring . 

STK 

MTASS 

(^MQPSS) 

„,s -j|| 

r'' || 


™ ps Jit 

MSASS 

STK 


AutoProducts, 


► Flight 
Dynamics 


► Planning ♦ 
Scheduling 


► Archive + Assessment 

) Automation 

GMSEC approach gives users choices for the components in their system. The TRMM 
mission rapidly selected key components from the GMSEC catalog. 
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